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Remarks 

In the following, references to Applicants' Specification are to paragraph numbers in the 
application's patent application publication 2005/0076065. 

5 

Support for the claims as amended 

Applicants have amended their claims to set forth that the "aggregated entry'' includes a 

first field whose value is a metric value computed from a set of individual values 
of a field in the plurality of entries and a second field whose value is a 
10 representation of the individual values (claim I) 

In FIG. 3's table 301, the ''first field" is supported by No. of hits field 1 15; the "second 
field'* is supported by Set of hit times field 303; table 301 is described at [0031]- 
[0034]; the claim term "metric value" is defined at [0008]. As for new claims 49-56, these are 
15 addressed to the species of the inventions of claims 1 and 25 that is disclosed in detail in 
Applicants' Specification. See in this regard Applicants' Abstract, prior art FIGs. I and 2, and 
FIG. 3 and the discussion of that figure at [003 1 ]-| 0034]. 

Patentability of the claims as amended 

20 What Applicants are claiming 

There are two independent claims: claim 1 and claim 25, and claim 25 is a Beauregard form of 

claim 1. Claim I as presently amended reads as follows: 

I . (currently amended) A melhod of aggregating a plurality of entries in a table in 
a database management system into an aggregated entry in the table or another 
25 table in the database management system, the method comprising the step of: 

making the aggregated entry, the aggregated entry representing the 
plurality of entries and including a first field whose value is a metric value 
computed from a set of individual values of a field in the plurality of entries and a 
second field whose value is a representation of the individual values. 

30 

As pointed out in the discussion of support for the claims as amended, an embodiment of the 
claim is shown in FIG. 3 and described at [003 l]-|0034j. 

What the references disclose 
35 The references both describe data aggregation as it is employed in the multi-dimensional 
relational database systems which are used to analyze business information contained in 
relational database systems such as those used for on-line transaction processing. A 
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characteristic of such systems is that the data which is processed to do the aggregation remains 
available in the relational database system used for on-line transaction processing system after 
the aggregation is made for the multi-dimensional relational database system. Because that is 
the case, there is no need to make aggregated entries which contain both the aggregated value 
5 and a representation of the values used to make the aggregated value. As set forth above 
Applicants' independent claims as presently amended set forth such aggregated entries. The 
Bakalash and Lore references do not separately disclose such aggregated entries and disclose 
nothing which could be combined to disclose such aggregated entries. 

10 Bakalash 

Examiner cites paragraphs 25, 29 ; 55-57 ? 68 ? and 74 of Bakalash for disclosing Si the 

representation specifying the individual members of the set" ( i: a second field whose value is a 

representation of the individual values" in the amended claim), but the cited locations disclose 

only that prior an systems aggregate data |0025], dimensions along which aggregations may be 

15 done [0029], pre-aggregation and indices to optimize query access times [0055]-[0057], 

multiple aggregation hierarchies [0068], and kinds of aggregation and summary' tables with pre- 

aggregated results 1 0073 1-| 0074 1. None of this discloses the claim's "second field whose value 

is a representation of the individual values", or indeed the claim's 

aggregated entry representing the plurality of entries and including a first field 
20 whose value is a metric value computed from a set of individual values of a field. 

in the plurality of entries and a second field whose value is a representation of the 
individual values 

and as repeatedly pointed out in the course of the prosecution of this application, there is no 
25 such disclosure anywhere else in Bakalash. Indeed, one of the problems that arises from the 
lack of the "second field whose value is a representation of the individual values" is pointed out 
at 1 0077 1 : 

[0077] summary tables do not provide a mechanism that allows efficient drill own 
to view the raw data that makes up the summary table-typically a table scan of 
30 one or more large tables is required. 

Bakalaslrs solution to the problems of aggregation is the aggregation server of FIGs. 6A-6D, 

described beginning at |0 1 74|. As set forth at |()1 76|, 

[0176] The Aggregation Server of the present invention excels in performing two 
35 distinct functions, namely: the aggregation of data in the MDDB: and the 

handling of the resulting data base in the MDDB, for "on demand" client use. 
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None of this, of course, has anything to do with what is claimed in claim I . 



Lore 

5 Examiner cites Lore for teaching "the aggregated entry as explained by applicant". The cited 
locations are paragraphs [0035H0039), [0068]-|007ll, and [125] and [191]. What Lore 
discloses generally is a technique used in multi-dimensionaJ databases for mapping "fact table 7 ' 
values to be aggregated onto "aggregation buckets'' which contain aggregated values produced 
using the fact table values that are mapped onto the aggregation buckets. The aggregation 

10 buckets may be for different dimensions and cross products of the dimensions, for different 
levels of aggregation, and for different kinds of aggregation. The mapping is done by relation 
table 4, which is shown in detail in FIG. 5 and described beginning at [0083]. As FIG 5 and the 
discussion clearly show, the values being aggregated exist only in the fact table records and the 
aggregated values exist only in the aggregation buckets. The data structures of FIG, 5 contain 

15 neither values from the fact table records nor aggregation buckets, but instead merely map fact 
table records onto aggregation buckets, so that the aggregates may be rapidly computed from the 
fact table records. 

Beginning with the locations cited by Examiner, [0035]-[0039] describes how Lore requires 

20 storage only for the aggregates that actually are provided with data and how the techniques of 

his invention require only that each key that identifies fact data to be aggregated be mappable 

onto the aggregates associated with the key. [0068J- [0071 J explains Lore's aggregate level 

codes [0069], aggregate keys [0070], and detail keys [0071]. None of this has anything to do 

with claim Ps "second field whose value is a representation of the individual values 1 '. 

25 Moreover, as is clear from FIG. 5 and its discussion, the individual values being aggregated 

exist only in the fact table and the aggregation buckets contain only the results of the 

aggregation; here, too, there is nowhere disclosed claim I 's 

aggregated entry representing the plurality of entries and including a first field 
whose value is a metric value computed from a set of individual values of a field 
30 in the plurality of entries and a second field whose value is a representation of the 

individual values 

Paragraph [125] describes uses of the relation table: 
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|0125) The relation table 4 has three primary uses. Firstly, it provides information 
about the number of aggregate records for each level so that the index table can be 
populated. Secondly, it computes indexes of detail and aggregate keys that, when 
combined with the data from the index table, are used to locate the address of the 
5 aggregation buckets in the address file and the entries in the memory cache. 

Thirdly, it provides the list of aggregate records into which a given detail record 
needs to be aggregated. 

The foregoing merely restates what has been pointed out with regard to FIG. 5 and its 
10 discussion beginning at [0083]. Again, there is no disclosure of anything like either the claim's 
''aggregated entry" as a whole or the "aggregated entry's" "second field" As for [0.1911, the 
cited paragraph explains rolling memory cache 8 of FIG. 2. (0162] gives an overview of the 
memory cache: 

The cache structure in the presently preferred design eliminates the need for an 
15 expandable memory size. Three main components are involved in the whole 

cache structure: the memory cache, the address file, and the aggregate file. The 
memory cache stores aggregates in memory while the address and aggregate files 
together store aggregates in temporary files. 

20 The memory cache is thus part of the storage arrangements for aggregate buckets. [0191 ] adds 
to this the explanation that the rolling cache permits partial aggregation, i.e., aggregation either 
on the bucket in the memory cache, if the bucket is in the cache, or on the bucket's aggregate 
file, if that is where the bucket is. Examiner sees [0191] as "teaching in detail the function of 
the aggregated entry which includes a field that represents the individual members and these 

25 members are specified along with their addresses". The cited location simply does not do this, 
and it further does not disclose anything like either the claim's "aggregated entry" as a whole or 
the "aggregated entry's" "second field". Further, the mapping of fact values to aggregate 
buckets set forth in [0125] combined with the aggregate bucket implementation set forth in 
[0191] do not, when taken together, disclose either the claim's ''aggregated entry" or the 

30 "aggregated entry's" "second field". 



Patentability of the claims over the references 
Patentability of independent claims 1 and 25 

Neither of the references discloses the "aggregated entry" set forth in Applicants* independent 
35 claims: consequently, the independent claims as amended are not rendered obvious by the 
combination of Bakalash and Lore. Since that is the case, the references also cannot render the 
dependent claims obvious. 

10 

OID-2002-247-01 



oracleO 1.026 



ORACLE CONFIDENTIAL 



Independent patentability of the dependent claims 

As discussed in previous responses, the dependent claims set forth additional limitations that are 
not disclosed by the references, and are consequently independently patentable over the 
5 references. 

Chirm 2, 26, 5(1 and 54 

The additional limitation here is that the plurality of entries represented by the aggregated entry- 
are deleted. In both references, the aggregated values are in addition to the fact values from 
which they are made, and the fact values remain in the data warehouse or fact table after the 
aggregated values are computed. Indeed, because the fact values from which the aggregates are 
made remain in the data warehouse or fact table, there is no motivation whatever in the 
references for anything like the "second field whose value is a representation of the individual 
values'* of Applicants' claimed aggregate entry. 

Claims 49 and 53 

The additional limitation here is the use of aggregation by a management service in a database 
management system to collect information about the occurrence of events in the database 
management system. Taken either individually or in combination, the references do not disclose 
anything about this application of aggregation and claims 49 and 53 are independently 
patentable over the references. 

Claims 3-8, 27-32. 51-52, and 55-56 

The additional limitations in these claims all further limit the second field of the claimed 
25 aggregate entry. Taken either individually or in combination, the references disclose nothing 
like the aggregate entry- or its second field and all of these claims are independently patentable 
over the references. 

Conclusion 

30 Applicants have amended their claims to better define their inventions, have demonstrated that 
the claims as amended are fully supported by the Specification as filed, and have demonstrated 
that the amended claims are neither anticipated by the references nor rendered obvious by the 
combination of the references. Applicants' Submission has thereby fulfilled the requirements of 
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37 C.F.R. 1.1 11(b) and 37 C.F.R. 1.114(c). Applicants have further included the required fee 
for the RCE and the Request and respectfully request that Examiner withdraw the finality of her 
rejection and continue with the examination of the claims as amended. Please charge any- 
additional fees required for the amendment or refund any overpayments to deposit account 
number 501315. 



Respectfully submitted, 

/Gordon E. Nelson/ 
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Gordon E. Nelson 
57 Central St., P.O. Box 782 
Rowley, MA, 01969, 
Registration number 30,093 
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